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ABSTRACT 



Apparatus and method for computer network configuration 
and address mapping. The invention provides for connecting 
mobile laptop PCs' to a network, without the need to 
re -con figure its network configuration parameters every 
time. The invention includes a device having a protocol 
stack configured with a network level protocol address that 
identifies a first tap point of a local network, so as to provide 
for data communications between the portable device and a 
local device connected to a second tap point of the local 
network, when the portable device is connected to the 
network at the first tap point of the local network. The 
invention further includes network equipment for providing 
data communications between the portable device and the 
local device when the portable device is disconnected from 
the local network and is connected to a remote network, 
while still using the protocol stack of the portable device 
configured with the network level protocol address that 
identifies the first tap point of the local network. 

5 Claims, 37 Drawing Sheets 



103 



12»- 
12*- 



"Hl3 101- 



-127 
-13S 

PackM Contreflar -128 



I 



Local 
Conlnilsr 




StBdt 
Addrsw 




Gonvatof 


-135 


Cocnpsrator 
FraornsntBr 
Pacfcst Contraliar 

TrBnupittof 


-137 


Rotrtevw 

Racord 
Addrm | 


Addrw 

Addrw 


AddraM t 


ActtBM 



/ 



107 V^IOS 



StBdt 
_j Address | 

G«n«FBtor i 



IDBvica 



0 ^109 



05/24/2004, EAST Version: 1.4.1 




05/24/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 31, 2000 Sheet 2 of 37 



6,141,690 




05/24/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 31, 2000 Sheet 3 of 37 6,141,690 



Fig. 3 



Fig. 3A 



Fig. 3A 




Fig. 3B 


Fig. 3C 


Fig. 3D 



301 



■f Start j 
T 



Initialize: 

-Tracing & Logging Flags 

-Global Storage & Buffers 

-Find all tiie Packet Drivers 
that have been installed, 
get Handles for use In calling them, 
pass them the Addresses of packet-receivers 
(called when a packet anives) 

-Set each network interface into "Promiscuous Mode" 
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^ Cleanup and exit 
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Fig. 3B 



31 7r 




3-l9^.' Error? 



No 



i. 



321 r 



Initiate ARP for 
Default Gateway; 
(If Icnown) 



-Yes- 
325-^ 



Clean up 
and exit 



327" ^ Done ^ 
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323— \ Fig. 3C 



325- 




Scan through the receiver buffers, looking for 
a buffer that has a packet that has been received 
(Figs. 4A-4C illustrate how this is done) 



^-345 

Print Statistics i^Yes 



Cleanup and exit 




-Yes- 



343 



Done ^349 



Check for Portable Devices that 
have disconnected from the 
Remote Network by sending 
ARP's to all those which haven't 

sent packets in the last 60 
seconds. Portable Devices that 
don't respond to these ARP's in 
a preselected time (eg. four |~351 
minutes) are deemed to be 
disconnected. 

i 



Send Controller Advertisement at 
61 second intervals 



-353 



Send Bootp broadcasts (only if 
Remote Protocol address is not yet|..355 
known) 

i 
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Fig. 4A 



Fig. 4 



Fig. 4A 



Fig. 4B 



Fig. 4C 



405 



407 




413- 



Increment n-packets- 
recelved counter 



/Return 0 In^ 
^^^" Vcxfes. dl J 



Find the next-available buffer that Is empty. The preferred 
embodiment uses a global variable to hold the most-recently 
used buffer Index, and Is used so that a free buffer Is more likely 
to be Found on the first try. Another advantage Is that each 
buffer gets a fair chance at being processed (so that there Is no 
starvation of the last buffers). 



-415 



05/24/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 31, 2000 



Sheet 8 of 37 



6,141,690 



Fig. 4B 



increment n- 
drops counter 



C Return 0 in \ 
y cx.es.di / ^^^ 



Change buffer status to "LOADING". 

Store packet length (in bytes) in Packet-Buffers [Index]. recelved- 

len. Store 0 in Packet-Buffers [index].received-from. 

It should be noted that receiver 1 stores 1 1n received-from, .... and 

receiver 4 stores 4 In received-from. 




^ Return the buffer segment \ 
Address In es, offSet In dl, and\ 
packet length in cx (these are h425 

names of registers of a / 
y preferred microprocessor ) / 
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Fig. 4C 



^ Second up-call from 
packet-driver. 



•427 



Search buffers to find 
the one being reported 
ready. 



-429 



431 




433- 



Increment n-2nd up call misses 
counter. This is an indicator that 
the implementation is faulty (or of 
a buggy packet driver) because 
every 2nd up-call should be 
matched by a buffer. 



Check its packet type: If neither 
a Protocol nor an ARP packet, 
Set its buffer status to EMPTY. 
This frees the buffer quickly, sincep^^ 
only these packet types are 
Handled. 



Return 



^435 



I 

^ Return ^439 
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Fig. 5A 



Fig. 5 



Fig. 5A 




Fig. 5B 


Fig. 5C Fig. 5D 


Fig. 5E 


Fig. 5F 





501 



503 



Handle ARP^k 
\ pacl<et start J 




copy the sender's 
Destination Protocol 
Address 



-507 



Return without 
processing Packet 
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Fig. 5B 
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Fig. 5C 



515 




-No- 



<517 

portable ARPIng^^ygg 
for itself? 



Return ^ 51 i 



Search the portable device 
table for an entry whose ^gg-j 
Protocol Address matches 
the sender's 



523 




-No- 



Create a new entry in the 
table entry's time first 
used . <-Time row 



-525 



Copy cunrent time into entry's time-of last-use field. & into "last received" 
field. 

Increment the packets' bytes counters for the entry. 
Copy the sender's Protocol Address. Physical Address. 
Build an ARP response packet, sender Addresses are the Controller's, 
destinations are the portable device's (Protocol and Physical) 
Send th^ packet to the portable device. 



527 



i 



^ Return ^529 
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Yesi 




Fig. 5D 



533-1 



Build an ARP reply. 
Source Addresses (Physical and 
Protocol) are Controller's. Destination 
Addresses (Physical and Protocol) 
are the sender's. 



535 



I 



Return 



Search mapped-Address table for a 
match between this packet's "Sender 
Protocol Address" field and the table 
entry for the Portable Device's Protocol 
Address 



Search table of Portable 
Devices for a match 
between this packet's 
Destination Protocol 
Address & Portable Device's 
Protocol Address 



-541 




Send ARP reply, giving the 
Portable Device's Protocol & 

Physical Addresses as 
Source Address, and those 
of the sender as the 
Destination Address 



i 

Q Return ^547 
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553- 



Invalidate the table entry, send 
"close Local Controller 
Connection" message to 
Remote Controller 



Search mapped-Address table for 
a match between this packet's 
Destination Protocol Address field 
and the table entry for the Portable 
Device's Protocol Address 



-557 



^ Retum ^555 




Build an ARP reply, giving 
Portable Device's Physical & 
Protocol Addresses as Sender 
Address fields. The Destination 
Address fields are those of the 

Sender. Send the packet 



^ Retum ^563 



'561 
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/Did\ 
^ packet 

<^ arrive from 
Remote network 
\ interface? 



Fig. 5F 



Yes 



\ / 



Make sure there 
is an entry in the 
ARP cache for it 



No 



521 



Search the table 
of Portable 
Devices (by 
Physical 
Address) for a 
match 



No< Found? >583 





579 



Set the Portable Device's Protocol 
Address. 

Update the entry's time-of-last-use 
field. 



Return ^589 



-587 



577- ^Retum^ 
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Fig. 6A 



Fig. 6 



Fig. 6M 



Fig. 6K 



Fig. 6L 



Fig. 6A 



Fig. 6B 



Fig. 6C 



Fig. 6D 



Is the 
603^?^ Remote Net 
.Protocol Address, 
known? 



617 




Fig. 6E 



Fig. 6F 



Fig. 6G 



Fig. 6H 



Fig. 61 



Fig. 6J 



605J 



Call receive 
bootp to check if 
this is a bootp 
reply 



No— » ( Return ) ~619 



621- 



Get Protocol header 

length, Source & 
Destination Address 



bootp state <- 
61 3-] Ready ARP for |*-Yes 
Default Gateway 



623- 



Is this 
^a Control!er-to- 
Controller 
Protocol 
lessage'^' 



626- 



Call Handle 
Controller 
Protocol 




(Rei 



urn>615 
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Fig. 6B 
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NOTE: received a packet 
from Remote Network 



Fig. 60 




651- 



Search the table of Portable 
Devices for a Portable Device 
with this Protocol Address 



~655 



( Return ) 4No-<Found? 



Yes 

1 



r653 



Copy Portable Device's 
Physical Address into the 
packet Destination Address 
field. Copy the ether Address 
of the l-AN l/F to the Source 
Network Address. Update the 
Portable table entry time of 
last use field send the packet 
to the Portable 



1 r 

( Return 3-649 



~647 
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Fig. 6D 



Yes 



Copy the Portable s physical Aoaress to tne 
Destination Physical Address of the paclcet. 

Copy the Physical Address of the Network Interface, 
which will be used to the Source Address. 

Deencapsulate the pacl^et (copy the original packet 
header's data over the "Remote/Local Controller 

header" part). 

Send the packet to the Portable Device 



-667 



c 



Return 



J)-669 
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Search table or 

Portable 
Devices for a 
match, based on 

the Source 
Address of the 
packet 



-661 



Fig. 6E 



663 




665- 



Create new 
entry in table. 
Copy Physical 
Address, 
Protocol 
Address, update 
time-oMst use 
field 



Yes 



conditionally- 
compiled for disk-ful 
systems only 




bean Local 
Controller table. If 
match found, store 
Local Controller 
Protocol Address. 

Set the Local- 
Controller-is-known 
bit 





NO 



Update time-of-last-use field. If the Local-Controller-is -known bit is dear, 
copy Destination Protocol Address to the trial Local Controller Address. 
Increase counters for number of bytes and packets sent and received. 
Store the interface number of the interface where this packet came from 
in the table of Portable Devices. 



— r" 
671 



673^ 



Is the 

5estination Address on the sarrie" 
subnet as the 
Remote Network? 



-Yes- 
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Fig. 6F 



675 



Use the trial Local 
Controller Address 



679 




NOTE: packet from Portable Device going 
to some subnet other than the Local one. 



-667 



Create a new entry. 
Store the Portable Device's Protocol 
Address.and the Remote Controller's 
Protocol Address 



Yes 




Copy the index of the mapped-address 
entry into the table of Portable Devices. 
Copy the Local Controller (or trial Local 
Controller) Address into the mapped- 
Address entry. Update the time-of-last 
use field in the mapped-address entry. 



'683 



t 
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685 




Send Controller-proto-request message 
(using procedure send map table entry 
request) to the Protocol Address we are 
currently using as the Local Controller for 
this Portable Device. 



-689 



Yes 
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Fig. 6H 




Return V.693 



Destination Protocol Address 
<-Local Controller Protocol [-696 
Address 



Yes 



697^ 



Is tills 
'Protocol Address on" 
tlie same subnet as the 
Remote Network 
Interface? 



Lool(up Address <-Defeult 
Gateway Protocol Address 



Lookup Address <-Destinatlon 
Protocol Address 



-6101 



o 



Searcli ARP cache for a match 
to this Address 



-6103 
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Fig. 61 



6105 




Perform 
Remote/Local 

Controller 
encapsulation 
on the packet. 
Destination 
Physical 
Address Is taken 
from ARP cache 
entry. 



-6115 



Retum ^ ^117 



Perform 
Remote/Local 

Controller 
encapsulation 
on the packet. 
Destination 
Physical 
Address is set to 
the Physical 
Address of the 
Default Gateway 



/ 

— No-*{^ Return J 

packet is dropped 



6109 



-6111 



( Return }>6113 
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6131 6127 
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NOTE: Have received a packet from the Remote 
Network, and we are acting as a Local Controller 



Get the original Protocol header. 
Get the Destination Address. Check 
if packet is destined for this same 

subnet. If so. check ARP kVes- 
cache for this Protocol Address. 
Otherwise, check ARP cache for an 
entry to the Default Gateway. 



— I — 
6135 



613 



fas this 
icket addressed 
fo the Remote Netwo^i^ 
interface.and is this 
)acket encapsulated*^ 



No 



6137- 



Fig. 6K 



Search the mapped address 

table for an entry for the 
packet's Destination Protocol 
Address 



6141 



^ Return } ^No — <" Found? 

61 3> 




6143- 



Yes 
▼ 



Update table entr/s 
time-oMast-use 



6147' 



look-up Address <- Portable 
Device's Protocol Address 



♦Yes- 



Is the 
Portable Device'^ 
Protocol Address 
on the Local 
6145^subnet?, 



6149- 



look-up Address <- Portable 
Protocol Address 
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i 



Search ARP cache 
for match to look-up j-6 1 5 1 
Address 



6155- 



6157- 




Update ARP cache entry 
field for time-of-last-use 



Encapsulate packet to Physical 
Address defined by cache entry. 



( Return ^ 6159 



Encapsulate packet to 
Physical Address of Default 
Gateway 



6163 




ARP for look-up Address 


1 


r 



Q Return ^167 
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Fig. 6M 



6179- 




Udpate ARP cache entry 
field fortime-of-last-use. 
De-encapsulate packet & 
send to Physical Address 
defined by the ARP 
cache entry. 




r 



Udpate ARP cache entry 
field for time-of-last-use. 
De-encapsulate packet & 
send to Physical Address 
defined by the ARP 
cache entry. 



6173 



ARP for the look-up - . 
Address ^^^^^ 



6181~^ Return ^ 61 71 "(^Return ^ 
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700- 



Handle Controlier-to- 
Controller Protocol 



Do we 
(now our Remote 
internet- Protocot 
701V^cldress^. 

Yes 



Is the 

message Protocol 

^ version 
706^« = 2;^ 

Yes 



This process Is called for all UDP packets 
received which have Destination port - 32321 



-No-» ( Retunr> '703 



-No-*r Return ) 

1 — 

707 



Fig. 7A 



Fig. 7 



Fig. 7A 




Fig. 7B 


Fig. 7C 


Fig. 7G 


Fig. 7D 


Fig. 7H 


Fig. 7E 




Fig. 7F 



message 
type = 19? 
^ontroller-Proto- 
709V^equestL 



No 



Was the 
destination Protocdh 
-YesK^ Address = Remote 
Network Protocol. 
71 lV Address?. 



713 
-No^ fRetum^ 

Ignore, 
message not 
meant for us 



Check if a mapped-address table already exists, 
searching by Portable Device's Protocol Address. If 
not found, create a new table entry for it storing the 
Portable Device's Protocol Address, the Local & 
Remote Controller's Address. Set time-of-last-use field 
In either case. Build Controller-Proto-Response packet 
and send back to Remote Controller. Preferably, build 
& send unsolicited ARP reply, so that machines on 
Local subnet have an opportunity to update their 
caches (but the operation of the invention does not 
necessarily depend on their doing so). 

I 



( Return > 71 7 



—f— 
715 
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message type = 29 (Controlter-Proto-Response) 

'19 Fig. 7B 




No 



No » {^ Return ) ~723 



Check mapped-Address 
table, searching by Portable 
Protocol Address 



-725 




729 

j_ 



Set "response 
received" bit in 
mapped-Address 
table entry 



730- { Return ) 



No> ( Retunn ) ~733 



Set "Local-Controller-is- 
Known" bit entry in table of |«735 
Portable Devices 



Do we ^^^737 
^'^ already have this 
Local Controller In our 
table of Local 
^^£ontro!lers^^" 

>^ 

741 -(^ Return y 



739 



>Non 



Add Controller to 
table & Address to 
file of Controllers 
(hControllers list) 
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Fig. 7D 




^^^^^^ 



No 



Build response entry. UDP message Format UDP date, 
byte 0 = 69; byte 1 = 2; 

bytes 2-3 = # of Portable Device entries in message; 
bytes 4-7 = Time-stamp when sent 
bytes 8 & following: 

repeat of this pattern for U entries: 
time-stamp of 1st use (4 bytes) 
time-stamp of last use (4 bytes) 
time-stamp of last rev. (4 bytes) 
Physical Address (6 bytes) 
Portable Device user's name (up to 80 bytes) 
mapped-table index (2 bytes) 
Portable Device's Protocol Address (4 bytes) 
Portable Device's trial Protocol Address (4 bytes) 

# of packets sent or received (4 bytes) 

# bytes sent or received (4 bytes) 
Interface number (1 byte) 
flags bits: 0 Entry in use, 

1 Local Controller known if Set 
Send the packet 



Yes 




( Return ^ 793 
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message type = 79, show Controller stats 




Fig. 7E 



Yes 




No 



Build a UDP message, 
port = 32321 
message type = 79 
message version = 2 

rest of UDP data area is a null terminated ASCII 
string, giving the values of various stats the 
Controller collects. 
Send the packet 



-7001 



( Return )~7003 
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Fig. 7F 




(Return > 7013 
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message type=39, the 
"tear down the Remote/ 

Local Controller 
connection" message 



Is 

there an 
entry in the mapped- 
address table for this 
Portable 
753^ Device? 



-Yes>| 
755 



Clear the in-use bit of the mapped- 
address entry, so that it is not a 
candidate for searches.and so that it 
is available for other uses. 



c 



T 



Return 



> 



757 



c 



No 

I 



Return 



> 



759 



Build a response message 
packet (message content 

will be the same except for 
message type, as shown 
below) 



message type=49, this is 
the beacon message that 
the Controller sends 

Note: no check for 
"Protocol addressed to us" 



~763 



Fig. 7G 




Yes- 



767- 



Message type< — Controller- 
Proto-Response 



Message type<-Controller-Proto- 
Local-Controller-Local Invalidate 
mapped-table entry (if one exists). 
This sends a "tear down Remote/ 
Local Controller connection" 
message to t he R|mote Controller 



-779 
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Fig. 7H 




771- 



Create an entry, copy sender's 
Protocol address into Portable 

Device entry, copy Physical 
address of Portable Device, set 
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Flags: In-use indicator 
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COMPUTER NETWORK ADDRESS 
MAPPING 

HELD OF THE INVENTION 

The invention relates to data cx)mnaunication and more 
particularly to an apparatus and naethod for computer net- 
work configuration and address mapping to provide 
convenient, secure and flexible high speed communication 
between devices on the computer network. 

BACKGROUND OF THE INVENTION 

Computer networks provide for data communications 
between data processing equipment. For example, data 
processing devices such as portable lap-top computers, 
desk-lop personal computers, file servers, mini -computers, 
mainframe computers, printers, and the like can be inter- 
connected using a computer network to advantageously 
share programs, data, and other information resources. 

Devices located in a proximate area are interconnected to 
one another on the same network sub -net. Remotely located 
devices are interconnected to one another on a different 
network subnet, however devices located in proximate and 
remote areas can be connected by connecting the network 
subnets. 

An example of a popular computer network is generally 
known as an "Ethernet" local area network, or as specified 
by the International Standards Organization in ISO 8802/3. 
Ethernet advantageously provides fast data transmission 
rates of 10 Megabits per second, and can be extended to 100 
Megabits per second or more. 

For network communication, each device is mechanically 
and electrically connected to the computer network at a 
respective tap point of the network. Each tap point of the 
network is identified by a respective computer network 
address. The computer network addresses are used in trans- 
mitting data between devices connected to the network. 

Data is transmitted over the computer network in format- 
ted data packets, each comprising, for example, an ordered 
arrangement of a preamble 101, a start-of-fi"ame indicator 
103, a destination address segment 105 for indicating the 
computer network address of a tap point of the network for 
receiving data, a source address segment 107 for indicating 
the computer network address of a tap point of the network 
for transmitting data, an information length segment 107, an 
information segment 111, and a frame check segment 113, as 
shown for example in FIG. 1. Other alternative ordered 
arrangements of segments within the complete data frame 
are also known to those skilled in the art. The computer 
network addresses are used by switching equipment of the 
network to control routing of the data packets. 

For typical network use, each device connected to the 
network must have a register entry of the respective com- 
puter network address (which is called an "IP Address", IP 
standing for Interact Protocol) for identifying the respective 
tap point of the network. For example, for typical network 
use of a portable lap-top computer in a particular ofiEoe, the 
portable lap-top computer must have a register entry of a 
first computer network address for identifying a predeter- 
mined tap point of the local network. If the portable lap-top 
computer is disconnected from the network, moved, and 
then reconnected elsewhere, for example for use in a remote 
conference room, reconfiguration is needed to change the 
register entry, so that the portable lap-top computer has a 
register entry of a second computer network address for 
identifying a second tap point of the network. Such recon- 
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figuration is~again required upon returning to~the"previous~ 
location, and once again for network use in each subsequent 
remote location. Performing such reconfiguration manually 
is a burdensome task and is prone to errors, especially for a 

5 typical computer user of business application programs, who 
is lacking in that particular technical skill. 

Even if such reconfiguration is correctly effected, other 
limitations still remain. Typically network security systems, 
firewalls, access control schemes, network file system 

10 (NFS), and the like limit access based upon computer 
network addresses and tap points of the network. 
Accordingly, a hypothetical network security system allows 
network access to important files on a file server using the 
portable lap-top computer in the particular office, because 

15 the network security system recognizes the first tap point of 
the network, and also recognizes the first computer network 
address that identifies the first tap point of the network. 
However if that portable lap-top computer is disconnected 
from the network, moved, reconnected elsewhere, such as in 

20 the remote conference room, and then reconfigured as dis- 
cussed previously herein, the network security systems 
refuse to allow access to the important files on the file server. 
This is because the network security system does not rec- 
ognize the second tap point of the network, and does not 

25 recognize the second computer network address that iden- 
tifies the second tap point of the network. 

So called "wire-less modems", cellular telephone 
modems, and the like provide some advantages, but there are 
also limitations. For wire-less modems, data rates are not as 
high as are as those achieved, for example using Ethernet, 
with a device that is mechanical and electrically connected 
to the computer network at the tap point of the network. For 
wire-less modems, different broadcast standards and 
schemes in different counties prevent convenient universal 
operation, while hard-wired network connections, for 
example Ethernet connections, are advantageously operat- 
ing all over the world. Furthermore, wire-less modems pose 
greater security risks, since wire-less data transmissions are 
more easily intercepted than with hard -wired network 
connections, such as Ethernet connections. 

What is needed is an apparatus and method for computer 
network configuration and address mapping to provide 
convenient, secure, and flexible high speed communication 
between devices on the computer network. 

SUMMARY OF THE INVENTION 

An apparatus and method of the present invention provide 
for computer network configuration and address mapping, 

50 so as to provide convenient, secure, and flexible high speed 
communication between devices on the computer network. 
In a preferred embodiment, the invention provides for con- 
necting mobile laptop PCs to a network, without the need to 
re -configure its network configuration parameters every 

55 time. 

Briefly and in general terms, the invention includes a 
portable device having a protocol stack configured with a 
network level protocol address that identifies a first tap point 
of a local network, so as to provide for data communications 

60 between the portable device and a local device connected to 
a second tap point of the local network, when the portable 
device is connected to the local network at the first tap point 
of the local network. The invention includes network equip- 
ment for providing data communications between the por- 

65 table device and the local device when the portable device 
is disconnected from the local network and is connected to 
a remote network, while still using the protocol stack of the 
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portable device configured with the network level protocol 
address that identifies the first tap point of the local network. 

In accordance with the principles of the invention, the 
network equipment includes a remote controller having a 
first network interface adapter for connecting with the 5 
portable device, and a second network interface adapter 
connected with the remote network. A local controller is 
coupled with the remote network, preferably through an 
Internet protocol network. The local controller is connected 
near the local device on the local network. 

For data communication with the local device, regardless 
of whether the portable device is connected to the local 
network or the remote network, the portable device gener- 
ates an initial data packet having a source address header 
that includes the network level protocol address that iden- 
tifies a first tap point of the local network, and a destination 
address header that includes the network level protocol 
address, that identifies a second tap point of the local 
network. 

20 

When the portable device is connected to the remote 
network, the portable device transmits the initial data packet 
to the remote controller. In response, the remote controller 
generates at least one subsequent data packet based upon the 
initial data packet, wherein the subsequent data packet has ^5 
a source address header that includes the network level 
protocol address that identifies location of the remote 
controller, and has a destination address header that includes 
the network level protocol address that identifies location of 
the local controller, and has an information segment that 
encapsulates the network level protocol addresses that iden- 
tify the first and second tap points of the local network. The 
remote controller then transmits the subsequent data packet 
from the remote to the local controller, preferably through an 
Internet protocol network. In response, the local controller 
then re-generates the initial data packet based upon the 
subsequent data packet, and transmits the re-generated ini- 
tial data packet to the local device. 

Other aspects and advantages of the present invention will 
become apparent from the following detailed description, 40 
taken in conjunction with the accompanying drawings, 
illustrating by way of example the principles of the inven- 
tion. 
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FIG. 1 shows a simplified block diagram of the preferred 
embodiment of the invention. 

FIG. 2 shows a partial block and message diagram, 
illustrating operation of the preferred embodiment of the 
invention of FIG. 1. 

FIGS. 3, 4, 5, 6, and 7 show flowcharts illustrating 
software employed in conjunction with the preferred 
embodiment of the invention. 

FIG. 8 is a diagram illustrating data structures employed 55 
in conjunction with the software of the preferred embodi- 
ment of the invention. 
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As shown in FIG, 1, the present invention provides for 
flexible mobile data communication with a local network 
101. A portable device 103 having a protocol stack 104 is 
configured with a network level protocol address 105 that 
identifies a first tap point 107 of the local network 101, so 65 
as to provide for data communications between the portable 
device 103 and a local device 109 connected to a second tap 



poinTllO of the local network 101, when the~portable"device 
103 is connected to the local network 101 at the first tap 
point 107 of the local network 101. 

As discussed in greater detail subsequently herein, the 
invention includes network equipment for providing data 
communications between the portable device 103 and the 
local device 109 when the portable device 103 is discon- 
nected from the local network 101 and is connected to a 
remote network 113, while still using the protocol stack of 
the portable device configured with the network level pro- 
tocol address that identifies the first tap point 107 of the local 
network 101. In FIG. 1, the portable device 103 is shown 
near the right side of FIG. 1 outlined in a dotted line for 
illustrating when the portable device 103 is connected to the 
local network 101. The portable device 103 is shown again 
near the left side of FIG. 1 in solid line for iUustrating when 
the portable device 103 is connected to the remote network 
113, 

In the preferred embodiment, the network equipment 
includes a remote controller 115 having a first network 
interface adapter for connecting with the portable device 
103, and a second network interface adapter connected with 
the remote network 113, A local controller 117 is coupled 
with the remote network 113, preferably through appropriate 
routers and an Internet protocol network 121. The local 
controller 117 is connected near the local device 109 on the 
local network 101, limited only by the distance requirements 
of the local network. 

As shown in FIG. 1, the portable device 103 includes a 
generator 123 of an initial data packet, which, as discussed 
in greater detail subsequently herein, has a source address 
header that includes the network level protocol address 105 
that identifies the first tap point 107 of the local network 101, 
and a destination address header that includes the network 
level protocol address 105 that identifies the local device 
coupled to the second tap point 110 of the local network 101. 
The portable device 103 includes a transmitter for transmit- 
ting the initial data packet 213 from the portable device 103 
to the remote controller 115, when the portable device is 
connected to the remote network, as shown on the left side 
of FIG. 1. 

The remote controller 115 includes a generator 125 of at 
least one subsequent data packet based upon the initial data 
packet, the subsequent data packet having a source address 
header that includes the network level protocol address 105 
that identifies location of the remote controller 115, having 
a destination address header that includes the network level 
protocol address 105 that identifies location of the local 
controller 117, and having an information segment that 
encapsulates the network level protocol addresses that iden- 
tify the first and second tap points of the local network 101. 

The generator 125 of the remote controller 115 includes a 
comparator 127 for comparing a length of a data message of 
the data packet to a predetermined value. A data message 
fragmenter 129 is for fragmenting the data message into an 
initial portion and a remainder portion if the length of the 
data message is greater than the predetermined value. A data 
packet controller 128 is for controlling generation of a 
subsequent data packet including the initial portion and 
generation of another subsequent data packet including the 
remainder portion if the length of the data message is greater 
than the predetermined value. 

In the preferred embodiment, the generator 125 of the 
remote controller 115 further includes a record entry 131 of 
the network level protocol address 105 for identifying the 
location of the local controller 117, which is associated with 
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a record entry of the network level protocol address 105 for 
identifying the second tap point 110 where the local device 
109 is connected to the local network 101. A record retriever 
133 is for retrieving the network level protocol address 105 
for identifying the local controller 117, based upon the 
network level protocol address 105 for identifying the 
second tap point HO where the local device 109 is connected 
to the local network 101. 

The remote controller 115 includes a transmitter 126 for 
transmitting the subsequent data packet from the remote 
controller 115 to the local controller 117. The local control- 
ler 117 includes a generator 135 for regenerating the initial 
data packet based upon the subsequent data packet. The 
local controller 117 includes a transmitter 137 for transmit- 
ting the re-generated initial data packet 213 from the local 
controller 117 to the local device 109. 

FIG. 2 shows a partial block and message diagram, 
illustrating operation of the preferred embodiment of the 
invention of FIG. 1, For data communication with the local 
device, regardless of whether the portable device is con- 
nected to the local network or the remote network, the 
portable device 103 generates the initial data packet 213. In 
the preferred embodiment, the initial data packet includes: 
seven bytes of a preamble; a one byte SFD; six bytes of a 
destination address (DA) header that includes the network 
level protocol address that identifies the second tap point of 
the local network; six bytes of a source address header that 
includes the network level protocol address that identifies a 
first tap point of the local network; two bytes for a protocol 
identifier number (PIN) of the packet; a data message is 
within forty six to fifteen hundred bytes of the information 
segment; and four bytes for the cyclical redundantcy check 
(CRC). 

When the portable device 103 is connected to the remote 
network, the portable device transmits the initial data packet 
to the remote controller 115 as shown in FIG. 2 and 
discussed previously herein. In response, the remote con- 
troller 115 generates at least one subsequent data packet 223 
based upon the initial data packet, wherein the subsequent 
data packet has a source address header (SA) that includes 
the network level protocol address that identifies location of 
the remote controller, and has a destination address header 
(DA) that includes the network level protocol address that 
identifies location of the local controller, and has an infor- 
mation segment that encapsulates the network level protocol 
addresses that identify the first and second tap points of the 
local network. As discussed previously herein, the local 
device is connected to the second tap point. Accordingly, 
since the address of the second tap point identifies the local 
device, the address of the second tap point is shown in FIG. 
2 as the local device address. For the sake of simplicity, the 
first local tap point address is shown in FIG, 2 as the local 
tap point address. 

As shown in FIG. 2, the remote controller then transmits 
the one or more subsequent data packets 232 from the 
remote to the local controller, preferably through an Internet 
protocol network 121, In response, the local controller then 
re-generates the initial data packet 213 based upon the one 
or more subsequent data packets 232, and transmits the 
re-generated initial data packet 214 to the local device 109. 

In the preferred embodiment, the functional blocks of the 
local controller and the remote controller discussed previ- 
ously herein are each embodied in a respective general 
purpose computer running software as described in the 
following flow charts and data structures as will be dis- 
cii&sed herein. Starting with the flowchart of FIG. 3A, the 
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software procedure begins at Block 3017Block 303"is the 
initialization of Tracing & Logging Flags and Global Stor- 
age & Buffers. The code scans for aU of the packet drivers 
that might be included as configuration items. There might 

5 be one, or there might be up to five. So it is scanned to see 
how many of them are installed and finding the means for 
calling them, called handles; passing the addresses for 
packet-receivers and set each interface into Promiscuous 
Mode. Then there *s a check to make sure that at least one 

10 packet driver was found. If none, then it was not set up right 
so that's there's a clean up and an exit. The "Done" means 
the program is done. 

In Block 311, there's a check to see if more than one 
packet driver was found. If only one was found, then the 

15 Operating Mode becomes that of the local controUer, as 
shown in Block 313. Otherwise, the Operating Mode 
becomes that of a remote controller shown in Block 315. 
Those are mutuaUy exclusive so that by Block 317 the 
Operating Mode has been set to either remote controller or 

20 local controUer. 

Then the program reads through the Configuration File in 
Block 317. Block 317 is a simple parsing. It reads through 
an ASCII file, detects if a key word matches certain strings 
it is looking for, then takes the ASCII for the parameter and 
stores that value, does a little bit of error checking. As shown 
in the flowcharts, any box that's in dotted lines is present 
only in versions of the code for local or remote controllers 
that have access to a disk. Of course, there would be no point 
in having code that can read from a disk in a configuration 
that has no disk. 

Moving down to Block 319, the software checks to see if 
there is any configuration errors in that file. If there were, 
then in Block 325 there's a clean up and exit. The clean up 
closes log files, restores the LAN drivers to non- 
Promiscuous Mode and turns them off so they don't inter- 
rupt into code that doesn't exist anymore. 

If there were no configuration errors, the execution of the 
software moves from Block 319 to Block 321, it's going to 

40 initiate an ARP (Address Resolution Protocol) used to find 
the Physical Address for the default network gateway. 
Execution of the software then enters the main loop at Block 
323 for scanning through all of the receiver buffers looking 
for a buffer that has a packet that has been received. So now 

45 moving over to Block 331, the procedure handleReceived- 
Packet is going to check to see if this packet is an ARP 
Packet. If it is, then it calls the procedure handleARPPacket 
in Block 333 and is described in FIG. 5 A, starting at Block 
501, as will be discussed subsequently herein. If it's not an 

50 ARP Packet, then it's tested to see if it's a preferred protocol 
packet. For example, in the preferred embodiment this is an 
IP Packet. If the packet is an IP packet, then procedure 
handlelPPackel is called in Block 337. If it's not an IP 
Packet and if it's not an ARP, they all come back down to 

55 releasing the buffer, that's in Block 339. It releases the buffer 
so it can be reused and then the procedure returns. 

Now moving on to Block 343. There's a check to see if 
any key on the keyboard has been pressed. If so, this is the 
signal to terminate the running of the program. Some 

60 statistics are printed and then the clean up and exit routine 
is called and then the whole program exits. The clean up and 
exit is Block 347 and then the exit is Block 349. If no key 
has been pressed at a console of the controller, then some 
housekeeping functions are done. The execution of the 

65 software looks for a disconnected portable device by send- 
ing ARPs to any the portable devices which haven't sent 
packets in the last 60 seconds. Those which haven't 



05/24/2004, EAST Version: 1.4.1 



6,y 

7 

responded to these ARPs in the last 4 minutes are deemed to 
have been disconnected and moved away (by their owners). 
It should be understood that execution of the software 
provides some time for dropped packets on some of them but 
they have to answer at least one of them in 4 minutes). If so 
the resources that they use in the tables are released, as 
shown in Block 351. 

After that, execution of the software sends Controller 
Advertisements at approximately 61 -second intervals. Con- 
troller Advertisements are messages that are sent out on the 
remote network so that when a portable device is plugged in 
to its local network, it realizes that it's back on the local 
network and any remote or local controller connections can 
be released. 

Execution of the software sends BOOTP broadcasts, but 
this is only done if the site Protocol Address is not yet 
determined. There's a feattire in the software that provides 
for configuration without the Protocol Address using 
BOOTP, as in Block 355, then execution of the software 
returns back to the main loop. 

Speaking now of FIG. 4Athat handles Receiver 0. There's 
also a Receiver 1 and Receiver 2, a Receiver 3 and a 
Receiver 4. There's a separate procedure for each network 
card. Everything about how they operate is the same except 
for which number they put in on the "receive from" part of 
the data structure. This is so that the rest of the code can 
determine if this packet came from a portable device or if 
came from the remote network. In the code there are 
receivers 0 through 4 but the operation of them is completely 
identical, with the single exception that when a packet is 
received there is a data structure that says how many bytes 
are in it and that it's busy, and there is another place where 
it says which interface card got it. So that when a packet is 
returned from that portable device, the software recognizes 
which one to send it to. Elsewhere in the code, some of the 
processing is different depending on whether it came from 
any portable device or whether it came from the remote 
network. 

The process of receiving packets happens asynchronously 
and is described in the flowcharts of FIGS. 4A, 4B and 4C. 
If a packet has been found, then the procedure (called 
handleReceivedPacket) goes back to the loop to scan for 
more buffers. Starting at Block 401 Receiver 0 Start, the first 
thing that happens is that the interrupts on the controller are 
disabled. That's Block 403. Now a check is made. This 
interface that we're talking about, this is a software 
interface, to packet drivers. A value in a register that 
determines whether it's the first time being called or the 
second time. The first time means that there is a packet that's 
coming in, and a buffer address is needed to provide for 
storage for the incoming packet. ITie second up-call is the 
signal to the software that the packet has been received and 
is now in memory. So, Block 405 is the test to see if it's a 
first up-call. 

Block 407 is for that case (the first up-call). The check is 
made to see if the packet is too big. If it's bigger than 1518 
bytes, it's too big to be a legal Physical packet and that's also 
sometimes referred to as a Jabber. If it is, then in Block 409 
execution of the software increments the statistic counter for 
the number of Jabbers that have been seen. This is some- 
times useful in trouble -shooting. If the packet driver inter- 
face says to ignore this packet, then execution of the 
software returns with a 0 in the registers cx, es and di, as in 
Block 401. Assuming it's not a Jabber, execution of the 
software goes to Block 413. Execution of the software 
increments the number of packets received counter. 
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Then in Block 415^ execution of the software finds the 
next available buffer that is empty. The software uses a 
global variable to hold the most-recently-used buffer index. 
Accordingly, execution of the software doesn't keep reusing 
5 the same ones. Execution of the software spreads things out, 
so as to find an available buffer in an efficient amount of 
time. 

Moving on to Block 417. If no buffer was found, execu- 
tion of the software moves over to Block 419. Execution of 

10 the software increments the number of drops counter. If 
there is no place to put this packet, then execution of the 
software ignores it in Block 421. If a buffer is available, then 
in Block 423 execution of the software changes the buffer 
status to loading, stores the packet length in bytes. In the 

15 Packet-Buffers array the field is called Received_len. 
Execution of the software stores 0 in the Packet Ready 
Buffer. The order of these two is to ensure that in execution 
of the software there are no race conditions between the code 
that happens here in FIGS. 4A through 4C that's happening 

20 asynchronously and on an interrupt basis, and code near the 
top half of the kernel, which is looking for buffers. The 
software ensures that a buffer is available before the packet 
is completely loaded into that buffer. 

Then at Block 425, execution of the software returns the 
buffer segment Address in the es register, the offset in the di 
register, the packet length in the cx register. These are all 
names of registers in a preferred embodiment, which uses an 
Intel microprocessor. 

In the second up-call in Block 427 the packet is ready to 
be received. Execution of the software searches the buffers 
to find the one that's being reported ready, in Block 429. In 
Block 431 execution of the software checks to see if one was 
found. If not, in Block 433 increment the counter for the 
second-up-call misses. That's an indicator that the imple- 
mentation is faulty, or of a buggy packet driver because 
every second-up-call should be matched by a buffer. Then 
the procedure would return in Block 435. 

Finding one in Block 437, execution of the software 
checks its packet type. If it is not an ARP packet and it's not 
an IP Protocol packet, then execution of the software puts 
the buffer status to EMPTY. This is an optimization. It helps 
to cycle the buffers through a lot more quickly because there 
are a lot of other types of packets that can be received on the 
network that the software doesn't do anything with, and 
would ignore. So the sooner those packets get recycled, the 
better. Then the procedure returns in Block 439. 

In the flowcharts of FIG. 5, start of the procedure of 
handle ARPpacket begins in Block 501. In Block 503 execu- 

5Q tion of the software performs a test for the Protocol Address 
of the site Network. That would come in from either BOOTP 
responses from the broadcast or from the parsing of the 
ASCII text file. As provided in Block 505 if the Protocol 
Address of the remote network is not yet determined, 

55 execution of the software returns without processing the 
packet. If the remote network Network Protocol Address is 
determined in Block 507, execution of the software copies 
the-sender destination's Protocol Address, 

Block 509 determines if this is an ARP Request. If it is 

60 not, then execution of the software checks to see if it is an 
ARP reply. If it's not that, there are other ARP or RARP 
combinations that it could be. In Block 513 execution of the 
software returns without processing the packet. 

At Block 515, the packet is an ARP Request. Execution of 

65 the software checks to see did it come from one of the 
network interfaces of the portable devices. If it did, then 
execution of the software checks to see if the portable device 
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is ARP'ing for itself. On boot up they do that. If that's the 
case, then in Block 519 execution of the software returns 
without processing the packet. If execution of the software 
answers that ARP, then the portable device would operate as 
if some other machine on the network had its Protocol 
Address and it would slop talking on the Network and 
provide an error message saying some other device its 
Protocol Address. 

Moving on to Block 521, execution of the software 
searches for the portable device table for an entry whose 
Protocol Address matches the sender's. In Block 523 execu- 
tion of the software checks to see if this was found. If not, 
in Block 525 execution of the software creates a new entry 
in the table. The Entry's time-first-used is timeNow, which 
is used for some of the management protocol messages. 

Block 527 converges Blocks 523 and 525, since either of 
those two end up in Block 527. Execution of the software 
copies the current time into the Entry's time-of -last-use field 
and also into the time-last -received field. These are used to 
check for portable devices that have been disco tuiected. 
There's no point in sending ARPs to portable devices that 
are already sending packets to the controller, because receiv- 
ing packets from them determines they are still there. 

Execution of the software increments the packet and byte 
counters for the entry. That's used for some management for 
tracking how much use the portable device is making of the 
Network. Execution of the software copies the sender's 
Protocol Address and Physical Address into the table entry, 
and builds an ARP-response packet. The sender address is 
the controller's, destination Address is the portable devices 
(meaning both Protocol and Physical Address). So now the 
ARP Request from the portable device is then as a response 
back to the portable device and the procedure returns in 
Block 529. 

In Block 531, this is an ARP request from remote 
network, not from one of the portables. So, the test is, does 
the destination Protocol Address in the packet match the 
remote network interface Protocol Address? If it does, then 
execution of the software builds an ARP reply. In Block 533 
execution of the software builds an ARP reply. Both of these 
source Addresses, meaning the Physical MAC Address and 
the network level Protocol Address, are that of the Control- 
ler. Both destination Addresses, again Protocol and physical, 
are the sender's. In Block 537, this is an ARP Request from 
the remote network and it does not match the Network 
interface of the Protocol Address of the remote network 
interface. So now execution of the software determines 
whether the operating mode is that of a Local Controller. If 
it is, then execution of the software searches the record of the 
map -Address table for a match between this packet's sender 
network level Protocol Address field and the table entry's 
portable device Protocol Address, as in Block 539. 

If the general purpose computer is not acting as a Local 
Controller, then in Block 541 execution of the software 
searches the portable device table for a match between this 
packet's destination Protocol Address and the portable 
device Protocol Address. In Block 543 execution of the 
software checks to see if this was found. If yes, the software 
sends an ARP reply giving the portable device's Protocol 
and Physical Address as the source Address, and the sender's 
as the destination Address. In Block 547 execution of the 
software returns. In Block 549 execution of the software did 
not recognize a match so there is a return. If execution of the 
software found a match in that search, that's labeled "yes" 
in FIG. 5E by Block 553. Then in Block 553, execution of 
the software invalidates the table entry, send a "close 
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Remdte/Locar cbblroller connection message" to the 
Remote Controller and then in Block 555 execution of the 
software returns. If execution of the software didn't find one, 
then in Block 557 execution of the software searches the 
mapped- Address table for a match between this packet's 
destination Protocol Address field and the table entry's 
portable device Protocol Address. 

In Block 559 execution of the software rechecks to see if 
one is found. If one is found, execution of the software 
builds an ARP reply, giving the portable device's Physical 
and Protocol Addresses as sender Address fields, and the 
destination Address fields are those of the sender, and 
execution of the software sends the packet back in Block 561 
and returns in Block 563. If one is not found in Block 559, 
then execution of the software returns in Block 565. 

In FIG. 5F Block 567, execution of the software checks if 
the packet arrived from the remote network interface. In 
other words, it came from the remote network. In Block 569, 
if it did come from the remote network, execution of the 
software determines whether the reply is from the default 
gateway. If it did come from the default gateway in Block 
571, execution of the software ensures that there is an entry 
in the ARP cache for the default gateway. In other words, the 
controller just got a packet from the default gateway, so its 
Protocol Address is known. Since its Physical Address is 
known, execution of the software enters it in the ARP cache 
if it's not already there. Both of those blocks (569 and 571) 
converged at Block 573, which is a test to see if there's an 
entry in the ARP cache which matches this Protocol 
Address. 

In Block 575, if the answer to that question is yes, then 
execution of the software sets the in-use indicator of the 
entry, stores the Physical Address of the sender in the entry, 
clears other flag bits of the entry and stores the current time 
(timeNow is what it's called in the code) in the time -of - 
last-use field. These time -of-last -use field things are used to 
make sure that when portable devices are disconnected from 
the controller, that their table entry resources are automati- 
cally cleared out from the controller. In Block 577 execution 
of the software returns. From Block 573, if the answer was 
no in Block 579, execution of the software returns and 
proceeds to Block 581 to search the portable device table by 
Physical Address for a match to this packet. 

In Block 583, execution of the software checks to see if 
a match to this ARP relply was found. If not, then it is 
ignored. If execution of the software found a match, then 
we're going to set the portable device's Protocol Address, 
update the entry's time-of-last-use field. This is done in 
Block 587, and in 589 execution of the software returns. 

As will be discussed in further detail subsequently herein, 
the invention includes a novel Controller-to-Controller 
protocol, which provides an efiBcient way of setting up data 
communications between the remote controller and the local 
controller, and also for maintaining statistics about opera- 
tion. When the Remote Controller sets up a Remote/Local 
Controller Connection, it needs to communicate to the Local 
Controller so that the Local Controller can reserve table 
space so that it can recognize responses coming back from 
the portable device's users' servers on the local network, as 
well as other local devices. In operation those local devices 
address their response packets back to the portable device's 
Protocol Address. It will be the Local Controller that will be 
the place those packets wiU be Addressed. They will be 
routed by the normal routers back to that point. So, the Local 
Controller has to pick them up and has to connect them out 
to wherever the portable device is. It has to have a table entry 
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that will allow him to recognize those packets and distin- 
guish them from the billions of other packets it is going to 
see that it ignores. 

The other parts of the Controller-to-Controller Protocol, 
some of them are used for management, for example by 5 
gathering statistics on operation. They are sometimes useful 
if you want to know if an controller is responding, or if it is 
doing anything. In proper operation, the controller should be 
incrementing at least some of those statistics. Some of the 
other statistics can be used for debugging, such as the 
number of jabbers, the number of drops, and so on. So, if 
there are some sort of operational problems, statistics pro- 
vide information as to whether these problems are caused, 
for example because of packet drops. Alternatively this 
possibility can be eliminated if those statistics are not being 
incremented. 

Starting on FIG. 6 A at Block 601, is the handle IP 
Protocol packet procedure. This is the code that handles any 
packet that's an IP Packet. In Block 603 we want to check 
to see if we know our remote network Protocol Address. 
Again, if the answer is no, then we call receive BOOTP to 20 
check if this is a BOOTP reply. If it is, did we learn our site 
Protocol Address? If the answer is no, then we simply return 
without doing anything with the packet. If the answer is yes, 
then execution of the software determines whether the 
default gateway and subnet mask are also ascertained. These 25 
are optional fields in the BOOTP reply (shown in Block 
611). If the answer to that is no, then execution of the 
software goes down to Block 615 and returns. If the answer 
to that is yes, then in Block 613 we set the BOOTP state is 
Ready and execution of the software transmits an ARP 30 
message to determine the default gateway. In Block 617 
Network Protocol Address has been determined and now 
execution of the software checks whether this is an Protocol 
version 4 packet. If it is, in Block 621 execution of the 
software determines the Protocol header length, the source 35 
and destination Address. 

In Block 623 execution of the software checks whether 
this a Controller-lo-Controller Protocol message. If it is, 
then execution of the software precedes to Block 625 and 
calls the procedure handleControllerPacket, returning in 40 
Block 627, and that returns from handleControllerPacket. 
Otherwise, if it's not a ControUer-to-Controller ftotocol 
message, in Block 629 execution of the software checks 
whether this packet from one of the portable device inter- 
faces. If it is not, then in Block 631 execution of the software 45 
checks if this is an ICMP "Ping" request. If it is, then in 
Block 633, execution of the software builds and transmits a 
ping response and in Block 635 returns. If it's not a ping 
request, then in Block 637, execution of the software checks 
for the operating mode as a Remote Controller. If so, then in 50 
Block 639 execution of the software checks to see if this is 
a Remote/Local controUer encapsulated packet. In other 
words, if the protocol number is 4. If the answer is no, then 
in Block 641 execution of the software searches the portable 
device table for a portable device with this Protocol Address. 55 
In Block 643 execution of the software checks to see 
whether one was found. If not, in 645, execution of the 
software returns. Otherwise, if one is found, then in Block 
647 execution of the software copies the portable device's 
Physical Address into the packet destination Address field, 60 
copies the Physical Address of the Network interface to the 
Source Physical Address, updates the portable device table 
entry time-of-last-use field, and sends the packet to the 
portable device. Execution of the software returns in Block 
649. 65 

In Block 651 execution of the software searches the 
portable device table for a portable device with this Protocol 
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Address. In Block 653 execution of the software checks to 
see if one was found. If not, then execution of the software 
returns in Block 655. Otherwise, execution of the software 
proceeds down to Block 657, found Yes. Then execution of 
the software copies the portable device's Physical Address 
to the destination Physical Address of the packet and copy 
the Physical Address of the Network interface which will be 
used to the source Address. We de-encapsulate the packet, 
copy the original packet header and data into the Remote/ 
Local Controller header parts, and send the packet to the 
portable device. Continuing in Block 657, we 
de-encapsulate and restore the packet, meaning copy the 
original packet header and data over the Remote/Local 
Controller encapsulation header part and then send the 
packet to the portable device. In Block 659, execution of the 
software return from the handleControllerPacket procedure. 

In Block 661 subsequent to Block 629, execution of the 
software determines that the packet is from one of the 
portable device interfaces. In 661 execution of the software 
searches the portable device table for a match based on the 
source Address of the packet. In Block 663 execution of the 
software checks to see if an entry was found. If no entry was 
found, then in Block 665, execution of the software creates 
a new entry in the table. Execution of the software copies the 
Physical Address, the Protocol Address from the packet into 
the table, and updates the time-of-first-use field. Some code 
is conditionally compiled for controller configurations hav- 
ing disks. In Block 667 execution of the software checks for 
operation as a Remote Controller. 

In Block 669 execution of the software scans the Local 
Controller table. If a match is found, execution of the 
software stores the Local Controller Protocol Address and 
sets the "Local Controller is known" bit in the portable 
device table entry. Both of paths of Blocks 667 and 669 
converge on Block 671 to update the time-of-last-use field. 
If the "Local Controller is known bit" is clear, execution of 
the software copies destination Protocol to the a current trial 
Local Controller Address. Execution of the software incre- 
ments counters for number of bytes and packets sent and 
received, and stores the interface number of the interface 
from which this packet came in the portable device table, to 
record which interface is used to send messages back to the 
portable device. The Remote Controller might have several 
Network interface cards for fan-out reasons. 

In Block 673 execution of the software checks whether 
the destination Address is on the same subnet as the remote 
network. If it is not, then in Block 675 execution of the 
software determines whether this is the Local Controller for 
this portable device. If it is not, then execution of the 
software proceeds to Block 677 to use the trial Local 
Controller Address. If the Local Controller is not known any 
other way, then a portable device can ping his Local 
Controller, and that's what this code is doing. So, both of 
those blocks (675 and 677) converge into 679, and execution 
of the software checks whether there is a mapped-Address 
entry for this portable device. In Block 681, if there is not 
then execution of the software creates a new entry to store 
the portable device's Protocol Address and the Remote 
Controller's Protocol Address. 

Both of those blocks (679 and 681) converge in Block 
683. Execution of the software copies the index of the 
mapped-Address entry into the portable device table entry, 
copies the Local Controller or trial Local Controller Address 
into the mapped-Address entry, and updates the time-of-Iast- 
usc field in the mapped-Address field. 

At Block 685, execution of the software determines 
whether a reply to a Controller-proiocol-request from what 
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it is currently using as the Local Controller for this portable Controller. Now the relevant tests are'whether this packet is 

device is received. If the answer is yes, then in Block 687, addressed to the remote network interface and whether this 

execution of the software determines anything from this packet is encapsulated. If the answer is no, then in Block 

Local Controller was received in the last 5 seconds If the 6137 execution of the software searches the mapped Address 
answer is no, then execution of the software proceeds to 5 table for an entry for the packet's destination Protocol 

Block 689. Alternatively, if the answer is yes, then go to Address. In Block 6139, execution of the software checks if 

Block 691. Block 689 drops into Block 691, and so the only it's found. If not, then in Block 6141 execution of the 

difference is that if nothmg is received from the Local ^fj^^re returns. In Block 6133, if the answer is yes, this 

ControUer in the last 5 seconds, execution of the software , ^et Addressed to the remote network interface and 

sends a Controller-lo-Controller Protocol request message encapsulated. Then in Block 6135 execution of the 

using the procedure sendMapTableEntiyRequest) to the ^^^^^ .^^j p^^^^^^j ^^^^^^^ ^^^^-^^^ 

Protocol Address currendy used as Local ControUer for this ^^^^^^^ ^^^^^ y.^^ j^^ti^^ 

portable device. If that is the Loca Controller, then that will ^^^^ ^^^^^^ jf ^^^^^^ ^^^^^ ^^.^ p^^^^^^j 

refresh the mapping for this portable device in case it got Ic^t ^^^^^^ Otherwise, it checks the ARP cache for an entry 

or the Controller crashed. Both of those blocks converge in default eatewav 

Block 691 where execution of the software determines the , t^, , ^^^^ ^ . . r ,x 

Local Controller for this portable device. If the answer is no, ^ '° <'"9' 'f the answer is yes (an entry was found), 

then execution of the software returns in 693. Otherwise, if Block 6143 execution of the software updates the 

yes, then in Block 695 execution of the software sets the * time^f-lasi-use. In Block 6145 exeoiUon of 

destination Protocol Address to the Local Controller's Pro- ,„ the software tests whether the portable device Protocol 

tocol Address Address is on the local subnet. If yes, then in Block 6147 the 

r ni 1 i:n-9 *• c *u 4:* j * • look-up becomcs the portable device Protocol Address. 

In Block 697, execution or the software determmes ^. , ^^a^x ■ ^^^^n.u , , 

t- r» ! 1 Ajj • L * Otherwise, if no (in Block 6145), then in 6149 the look-up 

whether this Protocol Address in the same subnet as the . . i_i j • r. . i * jj 

^ A • ^ r .J. • Address becomes the portable device Protocol Address. 

remote network interface, so as to determme whether the ^ 

gateway is used. In Block 699, execution of the software ^^o^k 6151, execution of the software searches the 
looks-up on the default gateway Protocol Address. ^^^^e for a match to look-up Address. In Block 6153 
Otherwise, in Block 6101 execution of the software does a execution of the software checks if it's found. If yes, then in 
look-up on the destination Protocol Address, That would be ^^o'^*^ J^^^S, execution of the software updates ARP cache 
the case for sending to the same subnet. Both of those blocks ^ntry time-of-last-use field. In Block 6157 execution of the 
(699 and 6101) converge in Block 6103 to search the ARP software encapsulates the packet to the Physical Address 
cache for a match to whichever of these two Addresses is ^^^"^^ cache entry and transmits it. In 6159 execu- 
going to be used. In Block 6105, if not found, then execution ^1°° of the software returns. Otherwise, if execution of the 
of the software determines the Physical Address of the software did not find an entry in 6153, then execution 
default gateway in Block 6107. If that is unknown, then in proceeds to Block 6161 to determine the Physical Address of 
Block 6109 execution of the software returns and drops the 35 ^^^^""^^ gateway. If the answer is yes, then proceed to 
packet. In Block 6111 if the default gateway map Address is ^^ock 6163. If the answer is no, then execution of the 
known, then execution of the software encapsulates the software proceeds to Block 6165. In Block 6163, the con- 
packet and sends it to the default gateway, returning in Block encapsulates the packet to Physical Address at default 
gjj^3 gateway. In Block 6165 execution of the software sends an 
Otherwise, if in 6105 execution of the software found the 40 determine the look-up Address, In Block 
entry, then the packet is encapsulated. The destination Physi- ^^^^ execution of the software returns, 
cal Address is taken from the ARP cache entry in 6115, and Moving on now to Block 6169, from Block 6135, execu- 
execution of the software returns in 6117. For the sake of of the software checks to see if this search found 
simplicity, in the flow charts, encapsulating the packets in something. If not, then execution of the software determines 
both of these blocks includes transmitting it. Moving on now 45 whether the Physical Address of the defauU gateway (in 
to Block 6119, from Block 673, execution of the software Block 6171) is known. If yes, then proceed to Block 6173. 
determines whether the destination Address is on the same If no, then proceed to Block 6175. In Block 6173 execution 
subnet as the remote network. If the answer is yes (in 6119), of the software updates the ARP cache entry's time-of-last- 
then execution of the software determines whether there is use field, de-encapsulates and re-generates the packet, and 
an ARP cache entry for this destination. If the answer to that 50 sends to the Physical Address defined by the ARP cache 
question is no, then in Block 6121, execution of the software entry. 

determines the Physical Address of the default gateway. This Proceeding to Block 6175, from Block 6173 or from a no 

is again doing as discussed previously herein, deciding answer in Block 6171, execution of the software transmits 

whether the map Address to send is determined, or whether an ARP message for the look-up Address. Then in Block 
the packet is sent by way of the gateway. If the gateway is 55 6177 execution of the software returns. Proceeding to Block 

not used, then in Block 6123 execution of the software drops 6179 (from Block 6169) if execution of the software found 

the packet and returns. If at least the gateway is known, then an entry, execution of the software updates the ARP cache 

in 6125 execution of the software copies the default gate- entry's time-of-last-use field, de-encapsulate and 

way's Physical Address to the destination Address of the re-generates the packet, and sends the Physical Address 

packet and sends the packet, and returns in 6127, defined by the ARP cache entry. In Block 6181 execution of 

If the ARP entry is known for where execution of the the software returns, 
software is trying to send this, then in 6129 execution of the In FIG. 7a, Block 701 begins the procedure handleCon- 
software copies the ARP table entry's Physical Address to trollerProtocol. This procedure is called for any message 
the destination at the Address of the packet and transmits the that's on the Controller-to- Controller protocol port numbers 
packet, and then execution of the software returns in 6131. 65 and which is addressed to this controller. Block 701 deter- 
In Block 6133, from 637, if the controller is not acting as mines whether remote network Protocol Address is known, 
a Remote Controller, that has to mean it is acting as the local In the answer is no, then in Block 703 execution of the 



05/24/2004, EAST Version: 1.4.1 



6,141,690 



15_ 



16 



software returns without doing anything to the packets, just 
ignoring them. If the answer is yes, then Block 705 deter- 
mines whether the message protocol version number is equal 
to 2. If not, in Block 707 execution of the software returns. 

The software executes a series of checks for message 
types. So, if the message type is 19 in Block 709, execution 
of the software proceeds to Block 711, to determine whether 
the destination Protocol Address is equal to the remote 
network Protocol Address. If the answer is no, then execu- 
tion of the software returns and the message is ignored 
because it's not meant for the controller. 

Of course the Network interfaces of the remote controller 
are set into Promiscuous Mode. If there happen to be several 
of these boxes on the same Network, they are going to be 
seeing each other's Controller-to-Controller protocol mes- 
sages. They need to ignore the ones that aren't meant for 
them. 

In Block 715, it means it was Addressed to this controller. 
Execution of the software checks whether a mapped - 
Address table already exists, searching by the portable 
device's Protocol Address. If not found, execution of the 
software creates a new table entry for it, storing the portable 
device Protocol Address, the Remote Controller and Local 
Controller Address, the time-of-last-use field in either case, 
meaning a case where an entry was found or the case where 
creation of a new entry was required. Execution of the 
software sets the time-of-last-use in either case, and builds 
an Controller-Protocol-Response packet and send back to 
the Remote Controller. Execution of the software builds and 
sends unsolicited ARP replies so that machines in the local 
subnet have an opportunity to update their caches. In Block 
717 execution of the software returns. 

In Block 719 if the message type was 29, then execution 
of the software proceeds to Block 721 to determine whether 
the message sent to this controller. If not, then in Block 723 
execution returns. Otherwise, if it was meant for this con- 
troller. In Block 725, the software checks the mapped- 
Address tables, searching by portable device Address. If 
found in Block 727, then execution of the software proceeds 
to Block 729. In Block 729, execution of the software sets 
the "response received" bit in the mapped- Address table 
entry and returns in Block 730. Otherwise, in 727 if no entry 
was found then in Block 731, execution of the software 
determines whether there is a portable device table entry for 
this. If not, then in Block 733 execution returns. Otherwise, 
in Block 735 the answer is yes, and execution of the software 
sets the "Local Controller Is known" bit in the portable 
device table entry. That means that the Local Controller is 
known, because it's just responded to the Controller-to- 
Controller protocol message, and only Local Controllers 
will do that. So for now on trial Addresses won't be used and 
this Address will be used. 

In Block 737, execution of the software determines 
whether this Local Controller is already in the table of Local 
Controllers. If the answer is no in Block 739, execution of 
the software adds the Controller to table and Address to file 
of Controllers. This is the table providing that, for a given 
Protocol Address, execution of the software determines the 
Local Controller to use in the future. That's one of the three 
methods for looking up which Local Controller to use for a 
given portable device. In both Block 737 and Block 739, 
they both converge on Block 741 which is just a return. 

Moving on now to Block 751, if the message type is 39, 
then execution of the software moves to Block 753, to 
determine whether there is an entry in the mapped- Address 
table for this portable device. If there isn't, then execution of 
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the software ignores it in Block~759. In Block 755 ^if yes; 
then execution of the software clears the "in use" bit of the 
mapped-Address entry, thereby making it available for other 
uses and not a candidate for searches. So, message type 39 
is the one that gets sent when the portable device discon- 
nects. This clears the entry, so the remote controller is going 
to inform the local Controller to clear the entry for this 
portable device it has moved. It returns in Block 757. 

In Block 761 if the message type is 49, then execution of 
the software moves to Block 763, and builds a response 
message packet. Message content will be the same except 
for the message as shown below. If the operating mode is as 
a Remote Controller in Block 765, then the message type 
will be a Controller-to-Controller Protocol Response as in 
Block 767. 

Block 769 determines whether there is a portable device 
entry for this portable device. If the answer is yes, then in 
Block 771, execution of the software creates an entry, copies 
the sender's Protocol Address into the portable device entry, 
copies Physical Address of portable device, and sets the 
time-of- first -use. If in Block 769 the answer was yes, we 
converge then in both cases to Block 773, so that execution 
of the software sets the "Local Controller is known" bit, sets 
the Local Controller Protocol Address field in the entry and 
copies the name of the user of the portable device from 
packet into the entry. Part of the Controller-to-Controller 
Protocol message includes a field that says the name of the 
user of portable device, for later extensions that would make 
it possible to find people when they are roaming around.. In 
block 775, execution of the software calculates the UP 
checksum for the packet and transmits the packet. In Block 
777 execution of the software returns. 

In Block 781, execution of the software determines 
whether the message type is 69. In Block 783, execution of 
the software checks whether the packet was received from 
the remote network. If it was, then execution of the software 
checks to see if the packet was Addressed to this controller. 
If it was not, then in Block 787 execution of the software 
returns. Otherwise, fi-om Block 783 if it was not received 
from the remote network, execution of the software proceeds 
to Block 789. 

If the packet was Addressed to this controller, execution 
of the software proceeds to Block 789, to build an entry for 
the response. It's a UP message and the UP data is byte 0 and 
contains 69 (decimal). Byte 1 contains a 2. Bytes 2 and 3 
contain the number of portable device entries in the mes- 
sage. This will be in Intel little-endian format, meaning the 
first byte has the least significant bits and the second byte has 
the most significant bits. Bytes 4-7 have a time stamp when 
sent, again in Intel little-endian format. Bytes 8 and follow- 
ing are repeat of this pattern for the number of entries. 
Time-of-first-use, 4 bytes, Intel little-endian. Time-stamp of 
last use, 4 bytes, Intel, little-endian. Time -stamp of last 
received packet, 4 bytes, Intel little-endian. Physical 
Address is 6 bytes. User's name is a null- terminated string 
up to 80 bytes. Mapped -table index is 2 bytes, little-endian. 
Portable device Protocol Address is 4 bytes, network byte 
order, which is in big-endian format. Portable device Pro- 
tocol trial Address is 4 bytes, network byte order. Number of 
packets sent or received is 4 bytes, unsigned, little-endian. 
The interface number is 1 byte. 

For the Flags bits: 0 means the entry is in use; Bit 1, if set, 
means the Local Controller is known. Bit 0 means the least 
significant bit of this byte. Accordingly, the aforementioned 
is the format of the message. 

In Block 791, execution of the software checks to see if 
there are more entries in the table. If the answer is yes, 
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execution of The software goes baclc up to the top and sen"d~ 
another such naessage. If the answer is no, then execution of 
the software returns. 

In Block 795, execution of the software tests the message ^ 
types. Message types 39, 49 and 69 have already been tested. 
In Block 795 execution of the software checks to see if it's 
type 79. If the answer is yes, then execution of the software 
proceeds to Block 797 and checks to see if the packet was 
addressed to this controller. If it's not, execution of the 
software returns in Block 799. If it was addressed to this 
controller, then in Block 7001 execution of the software 
builds a UDP message: the port is 32321; the message type 
is 79; and the message version is 2. The rest of the UDP data 
area is a null-terminated ASCII string, giving the values of 
various statistics the Controller collects. Message type 79 is 
just "send me certain sets of statistics". Sprintf ( ) is used to 
build strings of those, and then it sends the packet back. In 
Block 7003, execution returns. If the message type is not 69, 
79 and so on, then if it is 59 in Block 7005, then in Block 
7007 execution returns. If in Block 7009 the message type 
is 89, execution returns. Otherwise, in Block 7013 execution 
of the software returns. 

FIG. 8 is a diagram illustrating and summarizing data 
structures employed in conjunction with the software of the 25 
preferred embodiment of the invention and discussed pre- 
viously herein with respect to the flow charts. 

Although specific embodiments of the invention have 
been described and illustrated, the invention is not to be 
limited to the specific forms or arrangements of parts so 
described and illustrated, and various modifications and 
changes can be made without departing from the scope and 
spirit of the invention. Within the scope of the appended 
claims, therefore, the invention may be practiced otherwise 
than as specifically described and illustrated. 

What is claimed is: 
1. An apparatus comprising: 

a remote network coupled with a local network; 

a portable device coupled with the remote network for 
generating an initial data packet, having a source 
header of a first point of the local network, and destined 
for a local device coupled to a second point of the local 
network; 

a local controller; and 

a remote controller for generating from the initial data 
packet at least one subsequent data packet destined for 
the local controller and including a data message that 
encapsulates addresses of the first and second points of 50 
the local network; including 

a comparator of data message length to a value; and 
a data packet controller for one subsequent data packet 
if the data message length is less than the value, and 
for two subsequent data packets if the data message 
length is greater than the value. 
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2: An apparatus" comprising: 

a remote network coupled with a local network; 

a portable device coupled with the remote network for 
generating an initial data packet having a source header 
of a first point of the local network, and destined for a 
local device coupled to a second point of the local 
network; 

a local controller; 

a remote controller for generating from the initial data 
packet at least one subsequent data packet destined for 
the local controller and including a data message that 
encapsulates addresses of the first and second points of 
the local network; including: 

a comparator of data message length to a value; and 
a fragmenter of the data message into an initial portion 

and a remainder portion if the data message length is 

greater than the value. 

3. An apparatus as in claim 2 further comprising 

a data packet controller for controlling generation of the 
subsequent data packet including the initial portion and 
generation of another subsequent data packet including 
the remainder portion if the length of the data message 
is greater than the predetermined value. 

4. An apparatus as in claim 2 

wherein the remote controller further includes: 

a record entry of an address identifying the location of 
the local controller, which is associated with a record 
entry of the address identifying the second point 
where the local device is connected to the local 
network; and 

a record retriever for retrieving the address for identi- 
fying the local controller, based upon the address of 
the second tap point where the local device is con- 
nected to the local network. 

5. A method comprising: 

providing a local network and a local controller coupled 
with a remote network and a remote controller; 

providing a portable device coupled with the remote and 
a local device coupled with the local network; 

using the portable device to generate an initial data 
packet, having a source header of a first point of the 
local network, and destined for the local device coupled 
to a second point of the local network; 

using the remote controller to generate from the initial 
data packet at least one subsequent data packet, des- 
tined for the local controller and including a data 
message that encapsulates addresses of the first and 
second points of the local network; 

comparing length of the data message to a value; and 

generating one subsequent data packet if the length of the 
data message is less than the value; and 

generating two subsequent data packets if the length 
of the data message is greater than the value. 
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